PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/Delphi Digests/Delphi Vol. 3/Delphi 3.24

Text File | 1988-04-08 | 29.6 KB | 687 lines | [TEXT/ttxt]

28-Apr-87 14:38:07-PDT,30937;000000000001
Return-Path: <[e-mail]>
Received: from RELAY.CS.NET by SUMEX-AIM.STANFORD.EDU with TCP; Tue, 28 Apr 87 14:35:00 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa04606; 28 Apr 87 16:45 EDT
Received: from relay.cs.net by RELAY.CS.NET id aa01889; 28 Apr 87 16:41 EDT
Received: from slb-test by RELAY.CS.NET id ac01841; 28 Apr 87 16:37 EDT
Date: Tue, 28 Apr 87 16:18 EDT
From: Jeffrey Shulman <[e-mail]>
Subject: Delphi Mac Digest V3 #24
To: [e-mail]
X-VMS-To: IN%"[e-mail]"

Delphi Mac Digest     Monday, April 27, 1987         Volume 3 : Issue 24

Today's Topics:
     re: HD Backup directories
     re Icons in menus
     Dvorak Keyboard Layout
     Any engineers out there? (2 messages)
     re: SuperPaint, Aldus Prep, spelling che
     RE: MacFair II and the Macintosh II (4 messages)
     RE: sound problem
     ResEdit is not your friend (3 messages)
     Prototyper maker Addr wanted
     Response to DiskTime II Review
     Re: Reverting With the Resource Manager
     Switcher programming
     re: Writing for MacUser (warning)
     re: How to Change MS WORD 3.0 Menu Names
     MacFaire Rotterdam Part1 (3 messages)
     MPW C code resources
     word centering

----------------------------------------------------------------------

From: MACINTOUCH
Subject: re: HD Backup directories (Re: Msg 19216)
Date: 20-APR 11:37 Network Digests

Subject: HD Backup directories

DiskFit is indeed a nice program, but it's not a replacement for PCPC's
HFS Backup 2.0.  It doesn't have individual file and folder selection,
so for example, Word gets backed up over and over and over and you can't
exclude it (Word writes some dumb piece of data into itself).
Similarly, you can't exclude junk files you happen to have on the hard
disk. Also, since it reuses space on the backup floppies (an advantage),
it often makes you go through a large number of floppies as it removes
and updates data, even though your total changes would have fit onto a
single additional floppy.

I think DiskFit (in its present form) is a good program, but like an
automatic transmission on a car.  It's easy to drive, but lacks the
flexibility and controllability of a manual transmission (like HFS
Backup).

Both programs are evolving rapidly, and can be expected to soon share a
fairly complete set of features.

Ric Ford

(PS, As someone else mentioned, recovering data in HFS Backup, even
without the duplicate directory, is quite possible, and hence not an
issue.)

------------------------------

From: DDUNHAM
Subject: re Icons in menus (Re: Msg 19215)
Date: 20-APR 21:16 Network Digests

 >From: [e-mail] (Dave Wargo)
 >Subject: icons

As per IM I-347, menu icons are IDs 257-511.  In the menu itself, you
put the ID minus 256.

 David Dunham     "The more laws there are, the more people are
 Maitreya Design   inclined to break them"  (Swiss saying)

------------------------------

From: KELLYTH
Subject: Dvorak Keyboard Layout
Date: 20-APR 23:21 Programming

  This has nothing to do about laying out Dvorak with a Keyboard, but
more with a "personal" problem. I can't type QWERTY! I do know the
dvorak keys though. But I just traded my Macintosh Plus for an SE. Now
how do I get the old Dvorak back??????? The old patches don't work.
Local Apple Tech Support said "wow, that's a tough one". Please drop
E-mail to KellyTH Thanks a million.

------------------------------

From: VASMUG
Subject: Any engineers out there?
Date: 21-APR 05:22 Business Mac

Greetings,
     I'm hoping someone out there will be able to point me in the right
direction on a CAD program.
     Are you using a CAD program on the Macintosh?  What is the best one
out there?   Can you relate pros and cons about a program I should
purchase?
    Any and all help will be very much appreciated!
     Thank you. Fred Showker <VASmug>

------------------------------

From: PEABO
Subject: RE: Any engineers out there? (Re: Msg 19274)
Date: 21-APR 11:42 Business Mac

This isn't personal experience, but Jean-Louis Gassee was impressed
enough with Erez Anzel to mention that company's products specifically
during the Macworld keynote speech as examples of the forefront of
CAD-CAM on the Macintosh.

peter

------------------------------

From: DDUNHAM
Subject: re: SuperPaint, Aldus Prep, spelling che (Re: Msg 19249)
Date: 22-APR 01:46 Network Digests

 > From: David Wilson <WILSON/[e-mail]>
 > Subject: SuperPaint, Aldus Prep, spelling checkers

I don't think you got good advice about Aldus Prep.  The only time it
gets sent to the printer is when PageMaker prints.  Just having it in
your system folder won't cause it to be sent.  Once it's in the printer,
it sits there, taking up memory, until you reset (or turn off) the
LaserWriter.  I've never had problems running out of printer memory, but
I don't use large downloadable fonts, and I never smooth bitmaps (since
most of my bitmaps are screen dumps, which should NEVER be smoothed).

Does Spelling Champion know about curved apostrophes?

------------------------------

From: MACINTOUCH
Subject: RE: MacFair II and the Macintosh II
Date: 22-APR 09:29 Network Digests

RE: MacFair II and the Macintosh II

Thanks, Paul, for the excellent and informative report.  My only comment
is "150 software engineers!?!"

Ric

------------------------------

From: PEABO
Subject: RE: MacFair II and the Macintosh II
Date: 22-APR 12:36 Network Digests

I think it's a matter of discipline.  Nobody knows how to design a
personal computer with 150 hardware engineers; conversely, no one knows
how to design the software for one with only 4 software engineers.

If you think of how much information is tied up in a hardware design
versus how much is tied up in the software, you see the problem.  The
engineering drawings and the *hardware* part of the spec sheets of the
chips in the Mac II probably would fit in one or two hundred pages.  The
software specs are close to 3000 pages, and that doesn't count the
source code or any of the application software that Apple supplies.

The hairy edge of the hardware is in the glue chips that Apple is doing
with custom VLSI, such as the NuBus controller and the sound chip.  If
you included the insides of the sound chip, you might double the size of
the hardware spec. Maybe that's why they're supposedly having trouble
with it??

peter

------------------------------

From: MACINTOUCH
Subject: RE: MacFair II and the Macintosh II
Date: 22-APR 16:41 Network Digests

Heck, hardware is probably as much "source code" as software nowadays;
just a different language (nets and pins).  But I guess my big surprise
is a result of the impression that the original Mac, which was a much
bigger incremental step, seemed to have hardware and software both
designed by a team that totalled about a tenth as many people.

Ric

------------------------------

From: PEABO
Subject: RE: MacFair II and the Macintosh II
Date: 22-APR 20:00 Network Digests

[Oops, I misread your comment to say 10 times instead of one tenth ...
but I guess I'll just post the correction and leave the rest of my reply
in place.]

I don't think there were 1500 people involved in the original Mac.  Even
the Lisa team amounted to only 250 man-years, according to the mythology
of the times.  (Did I say 'only'? :-)

I think the hardware design is much smaller than the software design, in
some sense of number of bits.  Hardware is also much more tightly
constrained; two devices that are not on the same bus don't usually
interact to any great degree unless the design has a serious fault.
Hardware is compartmentalized by the mechaics of putting it together,
and the glitches in hardware are caused by funny timing problems, or
lack of noise immunity, or difficulties in guaranteeing a reliable
manufacturing process.

It's too easy to make software modules dependent upon each other in
subtle ways. It's fantastically easy to build complexity upon complexity
in software because it doesn't cost much more to manufacture a poorly
designed package in ROM than it does to manufacture a tightly designed
package.  Software can get out of control much more easily than
hardware, where you can't add a new function because there's no space on
the PC board to put it.

peter

------------------------------

From: DDUNHAM
Subject: RE: sound problem (Re: Msg 1457)
Date: 22-APR 01:48 Programming Techniques

No, it's not an intellectual puzzle.  The symptoms were a hang. I got
fed up and replaced the routine with void sound(pitch,duration) int
pitch, duration; {
        SWSynthRec      s;
        ParamBlockRec   pb;

        s.mode = swMode;
        s.triplets[0].count = (int)(783360L / pitch);
        s.triplets[0].amplitude = 128;
        s.triplets[0].duration = duration;
        pb.ioParam.ioRefNum = -4;
        pb.ioParam.ioBuffer = (Ptr)&s;
        pb.ioParam.ioReqCount = 8L;
        PBWrite(&pb,FALSE); }

In the process, I discovered that the LightspeedC assembler doesn't
recognize the macro _Write.  I'm also convinced there's a bug in their
StartSound glue -- I was hoping to hear from someone who _has_ used it.

------------------------------

From: PEABO
Subject: ResEdit is not your friend
Date: 24-APR 00:03 Tools for Developers

FLAME ON! I just got zapped by ResEdit in a particularly nasty fashion.
After working on a new utility program for several weeks, I was all
ready to send it out when I discovered that it crashed in its help
dialogs when run on a 64K ROM machine. After spending several hours
investigating, I found that 4 bytes of one of my StaticText items was
being moved over top of the text handle of the TERec that the Dialog
Manager uses to draw in the window (how, I don't know) and that the text
length field was negative (maybe sign extended from a one-byte value).
This led me to take a close look at the DITL in hex, and note that my
dialog contained a 243 byte item.  Thumbing through IM reveals that the
maximum length text item in a DITL is 240.  Evidently this limitation
doesn't apply on the 128K ROMs.

My flame is "why can't I depend on ResEdit to keep me out of trouble?"

Note that I was not editing the DITL in hex, I was using the Mac-ish
interface and I didn't know how big the string was (it's not that easy
to find out either
-- you have to know how to parse the DITL in hex).

Most compilers diagnose syntax errors.  They usually don't compile machine
instructions with unknown addressing modes.  Can't ResEdit enforce the laws of
Macintosh physics?
FLAME OFF!

Seriously, if this were the only thing wrong with ResEdit I wouldn't mind so
much.  A bug is a bug, after all.  The limitation of 240 characters is obscure,
and by and large it is worth the convenience of editing in a natural fashion to
put up with occasional problems.

But this isn't the only thing wrong with ResEdit.  Just to name a few things:

(1) Unnecessarily difficult method of putting DITL items in any particular
    order (and you nearly always want to put them in a particular order).

(2) No way to locate an item off the visible part of the window.  You have
    to edit in hex.  Very carefully.

(3) No sanity check on boundary boxes.  Type in the wrong digit on the right
    hand margin and poof!  Back to hex mode to find the BBox and make it
    well-formed again.

(4) No way to select an item by its number.  This would solve (2) and (3)
    if it existed and also would make it possible to create the user items
    that are used to refresh the outline around a button in a standard file
    dialog (BBox = (0,0,0,0)).

(5) Infuriating inconsistency in what double-click means when applied to a
    displayed dialog item.  Sometimes it means open the item for non-graphic
    editing, and sometimes it means open the associated resource.

(6) Strange results if you mistakely open an item twice because you covered the
    window from the first time you opened it.  That window is still there,
    waiting to be closed and undo your careful adjustments.

(7) Menu editor is numbingly slow.  It's too brain damaged to adjust the
    mask of enabled menu items for you.  You have to figure out the mask in
    hex and type it in.

(8) Font editor -- never mind.  Buy Fontastic: the Font Editor in ResEdit is
    an obscure practical joke.

This list could go on and on, but the picture is clear:  ResEdit isn't what it
could be, and certainly not what most of us imagined it would be back in the bad
old days when it was coming Real Soon Now.  I'll bet some enterprising Mac
hacker could produce a real Resource Editor that would blow it completely out of
the water.

peter                          "In any context, half of all references
PEABO @ DELPHI                  are local and half are global."

------------------------------

From: BRECHER
Subject: RE: ResEdit is not your friend (Re: Msg 1480)
Date: 24-APR 03:36 Tools for Developers

The menu editor can be changed from numbingly slow to pleasingly fast by
replacing the 8 BBITs in the TMPL with a HBYT.  One hardly ever alters the style
of a menu item, so not much is lost in going from 8 radio buttons to a hex byte.

(This idea due to Scott Knaster.)

------------------------------

From: RMUHA
Subject: RE: ResEdit is not your friend (Re: Msg 1480)
Date: 24-APR 22:27 Tools for Developers

Right on!  Didn't earlier versions of ResEdit have someone's name and address at
Apple (in the about box) requesting comments and complaints?  If so, you ought
to send them a copy of your screed.  It sums up the problem quite elequently.

You might add the fact that DITLs with large numbers of items are exceptionally
error prone.  When doing the MIDIScope, ResEdit just loved to crash whenever I
was changing the main window DITL (almost 50 items).  I learned to save the file
after each change, which is a pain since you have to close it and then re-open
it; there is no save command in the file menu.

------------------------------

From: UJL0013
Subject: Prototyper maker Addr wanted
Date: 25-APR 03:47 Business Mac

I'm so interesting of Prototyper made by SmethersBarnes. I want to know the
detail info but SmethersBarnes ad. has not their addr. Only their phone # is in
the ad. So, please teach me their mail address. I want to send them a letter
requesting detail information mail.

Thanx in your advance. - Masaaki

------------------------------

From: BRECHER
Subject: Response to DiskTime II Review
Date: 25-APR 05:32 Hardware & Peripherals

Charles McConathy of CMS Enhancements has kindly sent me a copy of "A Review of
DiskTimer II," by Jim Reekes of CMS's Tech Support.

DiskTimer II is a program I wrote and placed in the public domain, with source
code, which measures certain aspects of Macintosh hard disk subsystem
performance, namely data transfer rates for "large" (24KB) transfers, and an
indication of access time (head movement speed).  DiskTimer II is widely used as
an objective benchmark.  While I have never claimed that the results of
DiskTimer II's limited testing are correlated with user subjective speed
perceptions, the program does have value in relative comparisons if
intelligently used.  Among those who have found it of value (aside from disk
system developers) are the editors of MacInTouch magazine, who have been
extensively involved in testing and evaluation of hard disks; they found that
DiskTimer II results correlated reasonably well with perceived performance in
actual use.

While, as stated, DiskTimer II has its limitations, I'm afraid that the majority
of the points raised in Jim Reekes's review are based on errors and
misunderstandings.

The review discusses disk sector interleaving, and points out that DiskTimer II
favors disks with smaller interleave factors because DT II makes "large" read
/write requests.  It further points out (and quotes me to this effect) that for
a series of single-sector requests to consecutive logical sectors, a larger
interleave factor, on the order of 6:1, is better.

So far, so good.  But then Jim says, "[T]he Macintosh only makes single-block
requests. [p. 1]"  And, "[T]he FileManager of the Macintosh will only request
single block transfers. [p. 2]"  Now, I'm afraid this is silly.  The author(s)
of the Mac file system may have made a few mistakes, but that dumb they were
not.  Anyone who has any doubts on this score need only use a debugger to
intercept the _Read trap and examine those I/O parameter blocks which are
intended for the disk driver whilst copying a large file in Finder or loading a
large program.  The File Manager makes single-block requests only when it has
to, i.e., when an application makes a request that is less than or equal to a
block in size; or, when the application's request does not begin or end on a
block boundary then the File Manager must buffer the first/last block of the
request.  But when the Resource Manager, or an application, requests 100KB of
data, all or almost all of that data is obtained via a single request to the
disk driver (through the File Manager).

 > DiskTimer uses device manager calls directly.  It never issues calls
 > through the FileManager, which is [what applications use] in the real
 > world. ... This test is unfair and does not behave as a real applicaion
 > would.

I developed DiskTimer II *precisely* to avoid using File Manager calls, i.e., to
provide a benchmark that could be run without intializing the disk and that is
independent of the state of the file system on the user's disk.  If the file
system is used on a disk that is not specially prepared to match a standard in
its file configuration -- which is not reinitialized and carefully loaded with
the same files in the same order for all units under test -- then benchmarking
is hopeless due to varying degrees of file fragmentation and varying relative
distances between files or fragments, not to mention varying RAM cache sizes,
System versions, Mac ROMs, etc.  It is not possible to develop a meaningful
benchmark that does real-world tasks, does not require reinitialization of the
disk nor careful setup, and that provides results that are comparable among
different disks.  Given that constraint, DiskTimer II attempts to provide a
reasonably useful test of performance that may be run on any disk,
non-destructively, with no special setup, by any user.

 > One very important issue that is not even considered in DiskTimer results
 > is whether or not the manufacturers's SCSI drivers are performing any
 > verification of the data that was transferred.

(Other important issues not considered by DiskTimer II are pricing, support,
warranty, and noise level.)  Jim  refers to verification of "read/writes"; I
assume he means read-after-write verification of writes.  Most manufacturers
rely on ECC logic in the controller to detect and (in some cases) correct read
errors.

Jim then tries to scare users away from DT II:

 > Most importantly, DiskTimer should never be run on a disk containing user
 > data.  ... If you were to reset, power off, or get the bomb dialog during
 > a DiskTimer test, there is a chance of [losing] some data.

DiskTimer writes to the disk only data that was previously read from the same
location.  You are taking the same chance using DiskTimer -- and no more of a
chance -- than when using any Macintosh program that does disk I/O.  Let me join
Jim in advising that you should not reset or power off while *any* program is
doing disk I/O.  I have never had any reports of data lost (or of bombs) due to
DiskTimer II.

 > The seek test does not utilize the number of data surfaces ..., the number
 > of blocks per surface, or their size.

Right.  Why should it?  Do not confuse DT II's access time test with an attempt
to simulate hardware vendors' average access time statistic.  DT II measures the
time to do a series of single-block reads 1MB of "data distance" apart.  As Jim
notes, the result includes the single-block read times, which have nothing to do
with seeks.  But in most cases, the seek time overwhelms the read times, so the
confoundment is not significant.  He also notes that DT II has no way of knowing
that a seek has actually occurred; in fact, if the controller has an intelligent
cache, seeks will not occur -- DiskTimer II's access time is not valid for such
controllers.  But the results in such cases will almost certainly be so low (so
"good") as to immediately identify them as invalid.

 > And even more importantly, this seek test does not consider rotational
 > latency.

False.  As explained in the comments in the program source code, a random delay
(the same random pattern in each run of the program) is imposed between I/O
requests in order to avoid an accidental latency pattern that might be unfair to
some drives.  The net effect is to include average latency in the result, which
is not only fair but desireable.

 > Moreover, the DiskTimer seek test does not consider ... bad block
 > allocation.

This is why I solicited and published results from multiple testers for the same
brand of subsystem -- so that anomalies such as might be caused by attempting to
read a revectored block or track can be identified.

 > If one examines the DiskTimer results of the [DataFrame] 20, you'll see
 > seek times ranging from 38 to 80.  How can the same hard disk display such
 > variances?

Because it's not the same drive.  DataFrame has used different HDAs.  They are
currently using a faster-seeking drive than they did originally.

 > Worst of all, DiskTimer uses the Macintosh's internal [60Hz interrupt] to
 > calculate its resulting times.  SystemTicks are in 1/60th of a second and
 > DiskTimer is attempting to measure times in 1/1000th of a second! [There
 > follows considerably more material about how DiskTimer II is allegedly
 > attempting to measure individual disk reads or seeks by using the system
 > tick count.]

Huh?  DiskTimer uses the number of 60Hz interrupts to measure the elapsed time
from the start of a test until the end of a test; a test typically takes on the
order of two to twenty seconds.  For each iteration within a test, as stated
above, there is a random delay, and the 60Hz interrupt is used to impose the
delay, NOT to measure an individual disk action.  While there is an average of
1/120th sec error in measuring each delay, the errors are not cumulative except
for some residual bias which is constant for all tests.  As to "Inside
Macintosh's" warning, quoted by Jim, that the tick count may be inexact, it
helps to know *why* it says that, and under what conditions it may be inexact.
The count will be inexact only when there is a significant source of interrupt
latency such as lengthy floppy disk I/O.  It would be extremely ususual for such
interrupt hold-off to be present during a DT II run.

In sum, in view of the misinformation in the review, I believe that CMS is (with
all good intent) performing a disservice by distributing the review.

------------------------------

From: BRECHER
Subject: Re: Reverting With the Resource Manager
Date: 25-APR 06:23 MUGS Online

>To: [e-mail] (Ted Cohn)
>Subject: Re: Reverting With the Resource Manager

> Is there way to force the closing of [a] resource file without it being
> updated?

Clear the mapChanged bit, and then call CloseResFile.

------------------------------

From: DEWI
Subject: Switcher programming
Date: 25-APR 01:30 Developers' Corner

Does anybody know of a list of bugs/gotchas when playing around with Switcher
internals - using the LaunchSubTask hooks etc. I've managed to get things more
or less working - the only problem is the occasional infinite loop on launch
after a few launches and quits. I seem to remember some comments about Switcher
bugs when LSC 2.0 was released, but I wasn't sensible enough to save them.
     Many thanks,
       Dewi

------------------------------

From: DDUNHAM
Subject: re: Writing for MacUser (warning) (Re: Msg 19357)
Date: 25-APR 19:00 Network Digests

 >From: [e-mail] (Chuq Von Rospach)
 >Subject: Writing for MacUser (warning)

I assume you're aware that Robert Wiggins (RWIGGINS) is on Delphi?  Not that
he'd be involved directly, but it might be useful to shoot him some Email (it's
conceivable the post office lost the ms).

------------------------------

From: DDUNHAM
Subject: re: How to Change MS WORD 3.0 Menu Names (Re: Msg 19357)
Date: 25-APR 19:02 Network Digests

 >From: [e-mail] (Paul G. Nevai)
 >Subject: How to Change MS WORD 3.0 Menu Names?

Shortening menu names using Fedit+ should be easy.  Most strings are preceded by
their length (one byte).  Or, you could overwrite the extra part with spaces or
NULs.

------------------------------

From: INTECO
Subject: MacFaire Rotterdam Part1
Date: 26-APR 08:03 Business Mac

MacWorld Rotterdam  April 22-24, 1987 (1st Part, more tomorrow) This gives short
review of what could be found on the Expo. If there are same specific questions
I will try to help. This was the first MacWorld Expo in Europe. It was a bit
smaller than the Expo in Boston 1985, you could look at all the products well in
one and a half days. Nevertheless a lot of new products were presented or shown
for the first time in Europe. The most products were shown in the fields desktop
publishing, communication and hard discs. Abvent, France showed WorkStation, a
68020 clip-on card for the Mac+ which will work with 12 or 16 Mhz, 2 or 4 MByte
and optional 68881. Sorry forget to ask for the price. BUILD 123 is a management
and design tool for the housing industry for $595. From a ground plan it
produces automatically elevations. SIMUL is a program ($995) for  dynamic
modelling on the Mac+. It calculates movements at a speed of 3000 screens per
second. ACI, France 4th dimension 3.1, database, and Writer Plus, word
processor. Adobe impressed with the Illustrator. AST showed the Mac 286 in the
Mac II running which should be released in August. The Mac 86 board for the Mac
SE will be released in September. CDS, Netherlands, showed a Mac SE extension
card ($450) with 4 RS422 serial ports, one IEEE-488 port and optional 68881
floating point processor. The programmable controller IMC150 is designed in
first case for the OEM market ($500/1000 pieces) and will be available in a
month. This board connects to the AppleTalk, has its own Basic interpreter,
analog inputs and outputs, digital outputs, relays and communication ports.
D.O.S., Israel, released Laserpaint ($500) a program that integrates drawing,
painting, text and paste-up in one package, with the accuracy and precision
required by graphics designers. Laserpaint creates full color separations and
pure postscript output. Bitmaps of up to 600 dpi and fonts from 3 to 511 points
are supported. Interesting user interface. EMDAY, Belgium, the European
subsidiary of MAINSTAY showed V.I.P. 2.2 ($125) with modules  for matrix and
data base manipulation ($80). Translators ($90) in to Lightspeed C and Pascal
are available for the MPW languages they follow in May. A new product to be
released soon is Think`n Time, a visual idea processor, a desk accessory (23k)
written in assembler with a nice and fast graphical interface. It handles even
calculations and is compatible with MORE and Acta. INTERPROGRAM B.V:,
Netherlands, displayed its BLUES (Better Logic Using Expert Systems) tools. They
help to build and maintain systems specifications using Precendence diagrams,
System Flow, Nassi Schneiderman, Program Flow, Structure Chart and Data
modelling techniques (prices starting from $600). INVENTAB, Sweden, presented
MacAccess, a serial driver which can be connected anywhere on an AppleTalk
network. It is totally transparent to the using software. LaserAccess adds the
possibility for any computer with RS232 port and Postscript driver to use a
LaserWriter over Appletalk (no price yet, available in June). Jasmine
Technologies introduced MegaDrive ($999), featuring removable, 10 megabyte,
MegaFlopy ($59) diskettes. It is connected to SCSI and the motors turn off after
not in use. The speed of data transfer looks like the old Apple HD20. This is
the first product Jasmine is going to sell through dealers.

Uwe Goetzke

------------------------------

From: PEABO
Subject: RE: MacFaire Rotterdam Part1 (Re: Msg 19382)
Date: 26-APR 16:29 Business Mac

I'd be interested in knowing if BUILD 123 is primarily a tool for drawing or if
it also has things like parts breakdowns and cost estimation.  (I have CAD/CAM
on the brain, I think.)

peter

------------------------------

From: INTECO
Subject: RE: MacFaire Rotterdam Part1 (Re: Msg 19402)
Date: 26-APR 18:58 Business Mac

No Build123 covers the whole house building situation. Create a file of client
and site information. ENter your site plan showing boundaries, setbacks,
utilities, and trees. Develope floor plans for the house and automatically make
precise calculations of all surface areas. Add doors and windows, angle walls
and designate wall thickness. Create roofs and elevations for the house. The
area calculations can be read into a spreadsheet program for further
construction costs estimations. In the 2nd part of the report you will find a
description of MGM workstation which is a very complete mechanical engineering
package.

Uwe

------------------------------

From: DDUNHAM
Subject: MPW C code resources
Date: 26-APR 04:55 Tools for Developers

Hmm, I'm not too impressed with MPW.  A code resource I converted from Aztec C
to MPW C takes 19998 bytes, instead of 704.  I think this is because every glue
routine in the known universe gets hauled in.  I'm linking with

link -rt ACTf=64 -sn Main=a_TEXT -c Atxt -t ACTF
        a_TEXT.c.o -o d20:MPW:a_TEXT
        "{Libraries}"Interface.o
        "{CLibraries}"CInterface.o
(pretend there are partial derivatives at the end of the lines)

------------------------------

From: INC
Subject: word centering
Date: 26-APR 11:31 Business Mac

If you're left indent, but _not_ margin, is at .5" and the left margin is at 0",
and you center a line, it doesn't center from the left margin, but rather the
indent.  This also existed in 1.05 and seems like they don't think it's a
problem. Any views?

------------------------------

End of Delphi Mac Digest
************************